Power Tools 1993 November - Disc 2/Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso/hotlines/wsyhl/realrisc/realrisc.txt

Text File | 1993-04-20 | 24KB | 789 lines

REAL-TIME CONTROL UTILIZING RISC



Technical White Paper

December 1992

Robert L. Harris Research & Development Manager Measurement &
Control Systems Division Hewlett-Packard Company 3404 E. Harmony
Road Fort Collins, CO  80525



REAL-TIME CONTROL UTILIZING RISC



1.  Introduction



     The design requirements and tradeoffs for a Real-time
system utilizing a RISC-based processor will be reviewed.  The
definition of Real-time will be discussed. The design
considerations of a Real-time system utilizing the PA-RISC
architecture will be reviewed, including processor design,
memory subsystem design, I/O subsystem design, and operating
system design.



2.  Definition of Real-time



     The P1003.4 working group within the POSIX standards
effort has adopted the following definition of Real-time to
help guide it's activities:



     Real time in Operating Systems - The ability of the
operating system to provide a required level of
service in a bounded response time.



From this definition, and building upon our experience in
Real-time applications, the general attributes of a Real-time
system can be further broken down into the following areas:



Determinism:  The ability of the system to perform an operation
in a determined timeframe.

Responsiveness:  The ability of the system to quickly respond to
an external event.

I/O Flexibility:  The system's ability to flexibly perform I/O
and maximize user control over the I/O processes.

Reliability:  Maximizing system up time for critical conditions.



3.  General requirements of Real-time systems



     In order to fulfill the requirements for Real-time
control and computation, systems must satisfy the following
general conditions:



3.1.   High Computation Performance:

     While some applications require only a modest amount of
computation power, easily satisfied by
conventional CISC architectures, other applications, such as
high-performance data acquisition and Real-time
imaging, require very high performance processing power
provided by the 50-100+ MIPs power offered by RISC
processors.



     Processor power is typically measured by several CPU
benchmarks.  The most common are:



Clock frequency:  Used frequently in the past as a measurement
of the processor power.  However, with RISC and superscalar
architectures, the frequency of a processor seldom has a direct
correlation to it's actual performance.

MIPs:  Typically measured in Dhrystone performance, usually
expressed as a multiple of VAX 11-780 Dhrystone performance.
This benchmark measures integer processes per second and
record-pointer manipulation.

SPECmark:  A suite of 10 CPU intensive application-like programs
taken from the scientific and engineering environments that test
integer (SPEC int) and floating point (SPEC fp) performance of a
computer.



3.2.  Floating point performance:

     Floating point performance is becoming more important in
Real-time systems to give a wide dynamic range for data
computation, and in  graphics for both display and user
interface. As the technology has improved for
integrating floating point processors onto the processor
chip, more applications will take advantage of this power,
although certain low-end applications will
still not include floating point, or will include it as an
option.  Floating point performance is typically
measured in either:



Floating point SPECmark (SPEC fp)

Linpack:  A package of FORTRAN programs for numeric linear
algebra for testing a computer's floating point performance
(MFlops)

Whetstone:  Another benchmark program simulating
arithmetic-intensive programs used in scientific computing.



3.3.  High Performance Memory System:

     Processor systems require a reliable and high
performance memory system to gain optimal
performance.  Most RISC systems require cache memories, either
on chip or off chip, to perform well. Memory
system integrity is important for Real-time systems and vital
for mission-critical Real-time applications.
Parity (error detection) is the minimum acceptable;
ECC (error detection and correction) is preferred due to the
higher reliability.



3.4.  I/O Flexibility:

     Real-time systems are typically I/O intensive.  Most
systems are tied to a flexible, standard I/O bus such
as VME, EISA, S-bus, etc.  To obtain maximum flexibility the bus
should be standard and open.  Some built-in I/O
functionality is usually included.  This includes serial
  ports, parallel ports, SCSI interface, LAN interface, and
sometimes specialized interfaces such as IEEE 488
(HP-IB).



4.  The design of a Real-time system:



     In order to talk about the detailed design
considerations for a Real-time system, the following block
diagram of a Real-time system based on a RISC processor will be
used.  The block diagram is of the HP Model 742rt or 747i
Real-time systems based on the PA-RISC 7100 processor.



Figure 1 Real-Time System Block Diagram









4.1.  Processor:

     The heart of a Real-time system is the processor.  With
the increasing densities offered by current IC
technologies, processors have become more complex, offering
options for memory management, floating
point, and considerable I/O flexibility. These trends are true
in either RISC (reduced instruction) or CISC (complex
instruction) computers.  However, RISC
architectures have proven to provide more net performance per
unit cost of silicon, and thus have reached
acceptance in virtually all computer markets.



     RISC architectures evolved in their true commercial
sense during the 1980's. HP introduced the first RISC
machines in 1985 using a TTL implementation of the processor.
Since then, HP has produced several implementations in
both NMOS and CMOS.



In many ways, PA-RISC is a classic RISC architecture.  In
includes fixed size instructions, reasonably consistent
instruction formats, a fairly small number of addressing modes,
32 general purpose registers, and instruction formats that
permit hardwired implementation (no microcode) and reasonably
easy pipelining. PA-RISC, though, offers more instructions than
most other RISC architecture, and it is that richness in
combined instructions, such as combining condition branch
instructions with data operations, that leads to an excellent
match for Real-time control.



     Some of the relevant criteria when choosing a processor
are:



Integer computation performance

Floating point:  Standard or optional

Caches:  Are they integrated or external?  If external, what are
the timing requirements?

Memory management:  Does the processor support virtual memory
and thus an MMU,  or is it only physically addressed?  Physical
mapping is simpler and less costly, but eliminates the
advantages of an MMU in both addressing flexibility and process
protection.  Without an MMU, only a single,
unprotected address space is available.  The full UNIX model
of process to process, and process to kernel, protection cannot
be implemented.  A dynamic failure of a user task can cause
complete system failure.  With an MMU and protected process
environments, the MMU allows the failing task to suffer a
protection violation and possible termination without impacting
global system operation.  An MMU also allows for a virtual
memory option.



PA-RISC, along with several other architectures, defines several
levels ranging from 32-bit physical addressed to 64-bit full
virtual systems.  This scalability of processor performance and
cost is important to many applications.



Interruptions:  The processor should support both multiple
levels of maskable interrupts (PA-RISC offers 32) and one
non-maskable interrupt.

Fast interrupt response times:  In order to improve interrupt
response times, PA-RISC automatically copies the main registers
into "shadow registers", automatically saving the state during
short interrupt service routines.  The times required to store
and restore state, or "context switch time", are also important.

Debugging aids, to allow for system-level debugging.

Scalability and longevity:  The architecture should have room to
grow, both in performance, functionality, add-on processing such
as special function units and coprocessors, and address space.



The 7100 chip used in the 742/747 systems runs at clock rates up
to 99MHz. The 742 implementation consists of:



50MHz PA-RISC 7100 chip, implemented in 0.8u CMOS, which
includes:

IEEE 754 compliant single and double precision floating point

MMU with unified 120 entry fully associative first level TLB and
16 additional block        TLB

64Kb external instruction cache and 64Kb external data cache
(15nsec access time, 20nsec cycle time)



In a paper reported at OpenBus Systems '92, J.Petersen, C.
Dessonet, C. Parkman, Y. Perrin, and L. Tremblet from CERN
analyzed the performance of Lynx OS on both a CISC platform
(MVME 147, 68030, 25MHz) and a RISC platform (RAID 8235, R3000,
25MHz).  The performance reported:



Table I Performance Benchmarks





















The conclusion was that the data acquisition performance scaled
consistent with the Dhrystone performance.



4.2.  Memory Architecture:

      Following are the key elements in the design of the
memory subsystem:



Memory size flexibility (<4Mbyte to > 128Mbyte)

Performance

High bandwidth

Error correction

"Dual ported" functionality



The processor interfaces to memory and I/O through the processor
memory interface. In the case of the 742rt, this is through
PBUS, a 32-bit transaction-based bus supporting a wide variety
of transactional communications.  The processor memory interface
translates each PBUS transaction into the appropriate memory or
I/O action and response.  For simplicity of chip design and to
obtain the features desired, the processor memory interface was
split into two parts; a memory interface unit which responds to
memory commands and an I/O interface block which responds to I/O
commands.



In the system design, both parity and ECC memory designs were
considered. With the anticipated applications, parity would be
the minimum acceptable, but ECC was more desirable because of
error correction for single error conditions. An ECC design,
however, usually carries a penalty of either performance
(slower) or cost (more check bits).  The ultimate ECC design
solved both problems with a design that:



Had a 64 bit data path, allowing high performance while
remaining compatible with a  minimum configuration utilizing 9
RAMs.

Performed ECC over the full 64 bits, thus using the same number
of check bits as a  byte parity design would require.

Performed fast read-modify-write for byte, half word, or word
writes.  With write-back caches, the frequency of these
operations has decreased dramatically and was estimated to
minimally impact performance (<1%).

Increased reliability, from an estimated 3-6 months typical
between a parity error (based on our experience with parity
designs on similar systems), to a reliability that ranges in the
hundreds of years between non-correctable double-bit soft errors
with the ECC system.

Supports industry standard SIMM Memory Modules, thus allowing
the leverage of total industry volume of RAM modules.



4.3.   I/O Architecture:

The other portion of the processor memory interface on the 742rt
and similar RISC processors deals with I/O transactions.
Following is the block diagram of the I/O subsystem:



Figure 2 I/O Architecture






VME was selected as the standard bus for the board computer
(although, as the block diagram indicates, a path to EISA is
also available on an industrial workstation version).  Graphics
was anticipated as a future option, so a higher performance
internal system bus was also included, with functionality that
matched previous HP graphics system busses.  The I/O interface
block (implemented, in the 742rt, as a CMOS Standard Cell ASIC)
provides the means for I/O devices to do Direct Memory Access
(DMA).



4.3.1.   Built-in "Core" I/O.

The 742rt and 747i include built-in I/O common to many
processors designed for the VME and other busses.
Included is the following:



 A keyboard interface:  Popular interfaces are PS2 and Serial.
Hewlett-Packard has developed a daisy chain interface
(HP-HIL) which allows the interface of keyboards and other
user interface devices through one peripheral connector
(critical for preserving back panel connector space).

 Serial interfaces (2 EIA RS232C compatible with handshaking and
16 byte transmit and receive FIFO buffers).

 Parallel interface:  In most cases, the need is "Centronics"
compatibility.

 Networking:  In most cases, compatibility with IEEE 802.3 or
Ethernet is needed. In many Real-time applications, other higher
performance networking, such as FDDI, will become more popular
in the future.

 SCSI interface:   This is provided for interfacing disks and
other mass storage devices.

 Audio in/out.

 Time source:  Most operating systems require a source to update
the system clock.

 Time sources for event timing within the application (as
defined by Posix .4 extensions).  In the case of the 742rt, 2
16-bit programmable timers with 1 usec resolution and 1 microsec
to 65millisec time intervals were provided along with 1 32-bit
programmable timer.

 Bus error timers and a watchdog timer:  These provide the extra
security to force continued operation or a  reset of the system
in case of unforeseen error conditions.



4.3.2.   General Purpose I/O Interface:

Most general purpose Real-time systems will be interfaced to a
general purpose, usually industry standard, I/O bus.  Our
application was VME, although there are alternate standard I/O
busses such as EISA in common use.  The following table will
summarize some of the key attributes of some of the various
busses found in Real-time systems:



Table II Bus Comparison









5.  Real-time Software



     The software requirements of a Real-time system can
generally be separated into the broad categories of the
operating system and compiler technology.



5.1.  General attributes of a Real-time operating system

Real-time operating systems can generally be characterized as
having unique requirements in 5 general attribute areas:



Determinism

Responsiveness

User Control

Reliability

Fail Soft operation



5.1.1.   Determinism:

Determinism is the property of the system to perform an
operation in a well defined or deterministic time frame.
Ideally, the system would always perform an operation in a
pre-defined time.  However, all systems, including Real-time
operating systems, exhibit behavior which is less than fully
deterministic. The difference between a Real-time system and
those systems commonly classified as non-Real-time, is the
degree of deterministic behavior.  The degree of determinism is
usually specified by maximum interrupt response time (the
maximum time that interrupts are turned off usually dictates the
degree of determinism) and context switch time.



The deterministic, or guaranteed, response time, is usually
determined by one of two techniques, or a combination of the two:



 Manual inspection of worst-case timing paths

 Testing and measurement of worst-case timing paths, usually
during worst case kernel stress and configuration tests.



5.1.2.  Responsiveness:

Responsiveness is the ability of the system to respond quickly
to an event, external asynchronous interrupts.  This
differentiates a Real-time system from other "non-Real-time
systems", where synchronous events and responsiveness are not
nearly as key.  A low interrupt response time will usually
indicate a more responsive system.



5.1.3.  User Control:

A typical operating system has, as the highest priority, the
optimization of total system throughput and typically isolates
the user from direct configuration of the system.  However, a
Real-time operating system will give ultimate control of the
behavior of the  system to the user.  This starts with the
ability to set priorities for each task.  The user must be able
to reallocate the priorities on a Real-time basis.  The
Real-time system will also to allow the user to specify other
characteristics such as the use of paging, process swapping, and
privilege capability



5.1.4.  Reliability:

A failure in a personal computer, or other small system, is
typically not a catastrophic event.  A Real-time system is
frequently used to control mission critical processes and data
acquisition where a failure could result in serious loss of data
or property.



Various studies have been performed to estimate the "cost" of
quality.  The cost of fixing a defect, once a product is
deployed in the field, can reach gigantic proportions.
Hewlett-Packard takes the following steps to assure product
quality:



 Setting release criteria associated with quality, usually
associated with:

-Defect density

-Test coverage

-Inspection (Code review)

-PFA (Path flow analysis)

-Stress test (usually measured by meeting a certain number of
continuous hours of operation, or CHO, within a
stress environment)

-Performance



 Intensive code reviews and inspections during design and coding
to design out defects.  Most studies show that
finding defects with inspection is 10x more efficient  than
finding defects through test.

Execution of a test plan to verify conformance to the release
criteria



5.1.5.  Fail Soft Operation:

The ideal Real-time system will never panic or "crash".
Instead, when fatal conditions are detected, steps will be taken
to either correct or minimize the degree of the problem.  The
file system must be more reliable and can be characterized as
having Real-time extensions, including integrity in the event of
power failure or system problems.



5.2.  Operating Systems Alternatives:

With these considerations in mind, there are several options
available for the designer of a Real-time system.  One set is
Real-time kernels such as VxWorks or PSOS+, which are
characterized by excellent Real-time performance but with less
general purpose functionality and proprietary interfaces.
Another set is general purpose UNIX systems, some of which are
beginning to incorporate Real-time functionality into their
systems.  Several vendors exist for Real-time UNIX systems where
the programmatic interfaces are kept compatible with the UNIX
environment, but the focus is on Real-time. Lynx OS is one such
system and was selected as the core technology for the HP-RT
Real-time operating system for the 742.



5.3.  Application Programming Interface:

As HP has surveyed the Real-time market during the development
of HP-RT, the strong input was "support standards".  The support
of new hardware is limited by the industry's ability to create
software to provide solutions.  Evolving to standards will
improve the industry's ability to develop application software
in a timely manner, and will improve portability across
platforms.



The IEEE P1003 "Portable Operating System Interface POSIX"
working groups are working to address the requirements of the
portability of applications with Real-time requirements.
Although there are standardization activities in many areas, the
3 of most interest that form the foundation for HP-RT are:



POSIX 1003.1 System Interfaces

POSIX 1003.4 Real-time extensions

POSIX 1003.4a Threads within a single POSIX process



The POSIX 1003.4 standard contains interfaces in the following
areas:



Binary Semaphores

Process Memory Locking

Shared Memory

Priority scheduling

Clock and timers

Inter-process communication and message passing

Synchronous and asynchronous I/O

Real-time files



There are other defacto standards, such as Berkeley, System V,
X-Client, and Motif, and networking standards such as TCP-IP and
NFS, that are also important for Real-time applications,
especially if one is trying to port applications from other
environments.



The HP-RT operating system supports POSIX .1, POSIX .4, and
.4a, NFS, TCP-IP, and X-Client/Motif.



Drafts of the POSIX standards can be obtained from the IEEE
standards draft office distribution at [phone].



5.4.  Compiler Technology:

Compiler optimization technology unlocks the performance
potential of RISC architectures, including the PA-RISC
architecture.  The RISC design has fundamentally changed the
role of the compiler as RISC moves to strike a balance between
hardware and software that exploits the best of each technology.
 The resulting simple high performance instruction set enables
the compiler to apply optimizations that dramatically improve
performance.  The effectiveness of RISC depends on the
compiler's ability to create the optimal instruction sequences
by appropriately rearranging program steps.  Without these
optimizations many applications will execute at a performance
level far below their potential.



The importance of optimizing compilers was recognized during the
inception of RISC during the creation of PA-RISC in the early
1980's.  Since then, the evolution of HP's optimizing compilers
has been closely linked to both the evolution of advanced
optimization techniques and of the PA-RISC architecture. The
recent PA-RISC compilers have focused on improved instruction
scheduling, register re-association, software piplining, and an
enhanced register allocation, along with heuristic based branch
optimizations to get the best performance from the PA-RISC
architecture.  As one selects an architecture for Real-time, the
performance and capabilities of the compiler must be analyzed in
tandem with the hardware set.



6. Summary:



     The requirements and design of a RISC-based Real-time
system have been reviewed, including hardware and software.  We
believe, at Hewlett-Packard, that RISC competes effectively in
cost with CISC and surpasses CISC in performance potential.
With workstations and servers transistioning very quickly to
RISC, cost and performance will tip even more in the favor of
RISC architectures.

     The author acknowledges the many people at
Hewlett-Packard who have had a part in the development of the
PA-RISC system and in particular the development of the S700
Real-time systems and Industrial Workstation products.
Appreciation is also extended to Laura Karrington for her part
in preparing this manuscript.

References:



     1. Kevin D, Morgan, "The RTOS Difference", BYTE Magazine
Aug. 1992,

     2. Bill Corwin, "Adapting the POSIX Standard to
Real-Time", OpenBus Systems '92, p.21

     3. J.Petersen, C. Dessonet, C. Parkman, Y. Perrin,
L.Tremblet, "VMEbus Based Data Acquisition with
Real-time UNIX on CISC and RISC processors - Some Performance
Measurements",  Open BUS Systems '92 Proceedings,
p.99

     4. E. DeLano, W. Walker, J. Yetter, M. Forsyth, "A High
Speed Superscalar PA-RISC Processor",
Compcon II Spring '92 Digest of Papers, IEEE Press

     5. "HP PA-RISC Compiler Optimization Technology",
Hewlett-Packard Technical White Paper, Version
1.0, August 1992